I fear there will be many small issues with an a-frame upgrade, so I'll share them as I find them here:

• ground textures are too high [1] [2]

[1]

[2]

ground texture too high, you mean the ocean or the grass on the side? Or is there something else I don't see?

aframe 1.5.0

aframe master:

a tsunami is coming

The position of "Ground right • waterfront" didn't change, so what would be the code to look at for debugging the issue above? wobble-geometry-box maybe?

For the grass I don't see the issue

Ah okay it's when it's creating the scene from streetmix json the calculated position for the ground differ.
If I save a go back to aframe 1.5.0, it's still high.
So that would be an issue in the streetmix-loader component.

The water should be at y -3

Oh the change of position was synchronous in aframe 1.5.0. In aframe 1.6.0 and master (almost 1.7.0 really), the change is done at the end of tick.

groundParentEl.setAttribute('position', { y: -3 }); 
setTimeout(() => {
  console.log('groundParentEl', groundParentEl.object3D.position);
})

shows
{x: 30.55, y: 0, z: 0}

because

In aframe 1.5.0

groundParentEl.setAttribute('position', { y: -3 });
groundParentEl.setAttribute('position', { x: 30.55 });

gives

{x: 30.55, y: -3, z: 0}

In aframe 1.6.0

{x: 30.55, y: 0, z: 0}

The latest setAttribute call wins.

I guess we should review the code were we use an object with only x or y and set the position with groundParentEl.object3D.position directly.

no the setTimeout was already needed in aframe 1.5.0.
I think what changed is that giving a partial position will set the other coordinates to 0 in aframe 1.6.0.

@kfarr you need to explain to me how we get x -30.55 for the left side at the end. Both side are positive:

So the behavior of using partial object was never intended to work and it's not documented https://aframe.io/docs/1.6.0/components/position.html#main and here it works on aframe 1.5.0 only because it's not attached to the DOM yet. If it's attached to the DOM, setting the position with a partial object will have the other coordinates set to 0.
So with aframe 1.6.0, the behavior is the same, setting the other coordinates to 0, if you add the entity to the DOM before or after setting partial object.

let e = document.createElement('a-entity')
e.setAttribute('position', { y: -3 });
e.setAttribute('position', { x: 30.55 });
AFRAME.scenes[0].appendChild(e)
e.object3D.position
gives {x: 30.55, y: -3, z: 0} only on aframe 1.5.0 but that was an undocumented behavior
gives {x: 30.55, y: 0, z: 0} on aframe 1.6.0

let e = document.createElement('a-entity')
AFRAME.scenes[0].appendChild(e)
e.setAttribute('position', { y: -3 });
e.setAttribute('position', { x: 30.55 });
e.object3D.position
gives {x: 30.55, y: 0, z: 0} on both aframe 1.5.0 and 1.6.0

So we need to modify the code to use el.object3d.position.setY or setX instead or prepare an object and set it with setAttribute('position', obj) in one go. There may be also other part in the code were we set rotation with partial object as well we need to review.

Thanks for finding this. Yes in general the streetmix-parser logic is sloppy and written a long time ago using a variety of techniques. It does need refactoring, thanks for helping with this. I will test now but I assume somehow through magic the object3d is available to set prior to adding the entity to the dom.

Thanks for finding this. Yes in general the streetmix-parser logic is sloppy and written a long time ago using a variety of techniques. It does need refactoring, thanks for helping with this. I will test now but I assume somehow through magic the object3d is available to set prior to adding the entity to the dom.

No magic here, the object3d is created right away when you create a-entity
https://github.com/aframevr/aframe/blob/2aca98cbbc5f1f03431ce07f107709baa1718df8/src/core/a-entity.js#L34